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Abstract 


This document describes an Asynchronous Transfer Mode (ATM) package 
for the Media Gateway Control Protocol (MGCP). This package includes 
new Local Connection Options, ATM-specific events and signals, and 
ATM connection parameters. Also included is a description of codec 
and profile negotiation. It extends the MGCP that is currently being 
deployed in a number of products.  Implementers should be aware of 
developments in the IETF Megaco Working Group and ITU SG16, which are 
currently working on a potential successor to this protocol. 
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1.0 Conventions Used in this Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119. 


MGCP identifiers are case-insensitive. This includes package names, 
event names, local connection options and other elements of the MGCP 
header. 


2.0 Introduction 


The Media Gateway Control Protocol or MGCP [36] is used to control 
voice media gateways from external call control elements. Even 
though the bearer network might be IP, ATM, TDM or a mix of these, 
MGCP is transported over IP. Packages such as the MGCP CAS packages 
[38] are modular sets of parameters such as connection options, 
signal, event and statistics definitions that can be used to extend 
it into specific contexts. A related, IP-based mechanism for the 
description of ATM connections [18] has been generated by the IETF 
MMUSIC group. Due to the IP-centric nature of all aspects of the 
MGCP device control protocol, and for consistency with other MGCP 
package definitions, it is desirable to publish the MGCP ATM package 
in an IETF document. 


MGCP [36] allows the auditing of endpoints for package versions 
supported. The package version for the MGCP ATM package, as 
specified in this document, is 0. Even if the ATM package is the 
default package for some endpoints, the package prefix "atm" shall 
not be omitted in local connection option names, event names, signal 
names etc. If the ATM package is the default package for an 
endpoint, it will be listed as the first package in the audit 
response list. It is not necessary for the MGCP ATM package to be 
the default package for ATM to be supported on an endpoint. 


The ATM package in this document consists of Local Connection Options 
(Section 3.0), Events and Signals (Section 4.0) and ATM Statistics 


Parameters (Section 5.0). Section 6.1 has guidelines for consistency 
in the use of Local Connection Options. Section 6.2 describes codec 
and profile negotiation. Section 7.0 addresses security 
considerations. 
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In the ATM networks addressed in this document, services are carried 
directly over ATM without an intervening IP layer. The Local 
Connection Options, Events, Signals and Statistics Parameters 
described in this section are not needed for VoIP calls which can be 
carried, in whole or in part, over an ATM network. In that case, the 
constructs defined elsewhere for IP are sufficient. 


The ATM local connection option names, event names and signal names 
MUST always have an "atm" package prefix. Backward compatibility 
with older implementations that use X-atm as the package name is 
desirable. 


MGCP grammar [36] must be followed with regard to the use of white 
spaces. The examples in this document attempt to follow MGCP grammar 
in this and all other respects. 


3.0 Local Connection Options 


The Local Connection Options (LCOs) defined in this section are 
specific to ATM applications. Like other LCOs, these can be used in 
commands to create connections, modify connections and audit 
connections. However, unless noted otherwise below, they are not to 
be returned when an endpoint is audited for capabilities. 


ATM Local Connection Options are divided into the following 
categories: ATM bearer connection, ATM adaptation layer, service 
layer, ATM bearer traffic management and AAL dimensioning. 


When parameter values are represented in decimal format, leading 
zeros are omitted. 
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3.1 ATM Bearer Connection 


These local connection options are used to parameterize ATM bearer 
connections. 


TABLE 1: Local Connection Options for ATM Bearers 


4+--------- +--------------- 4--------------------------------------- + 
| Lco | Meaning | Values 

4+--------- 4--------------- 4--------------------------------------- 4 
| ct | Connection |AAL1, AAL1 SDT, AAL1_UDT, AAL2, AAL3/4, | 
| | Type |AAL5, USER DEFINED AAL 

4p--------- 4--------------- 4--------------------------------------- + 
| ve |vC/Bearer type | PVC, SVC, CID 

+--------- +--------------- 4--------------------------------------- t 
| se | Enable path | on, off 

| | set-up | | 
+--------—- +--------------- 4--------------------------------------- + 
| ci | Connection | See below 

| | Element | | 
| | Identifier | | 
+--------—- +--------------- 4--------------------------------------- + 
Connection type (ct): This parameter describes the ATM adaptation 


layer. The values that can be assigned to it are: AAL1, AAL1 SDT, 
AAL1_UDT, AAL2, AAL3/4, AAL5 and USER_DEFINED_AAL. The user defined 
adaptation layer is per amendment 2 of ITU-T 9.2931. 


Type of Bearer/VC (vc): This indicates whether a PVC, CID or an SVC 
is to be used for an ATM connection. Possible values are: PVC, SVC 


or CID. Omitting this parameter will result in the use of a default, 
which could be embedded or provisioned. The value "PVC" covers both 
classical PVCs and SPVCs. The value "CID" covers subchannels within 


AAL1 [35] and AAL2 [10] virtual circuits. A value of "SVC" for 
atm/vc does not necessarily imply that the addressed media gateway 
should initiate signaling for bearer set-up, since this might be done 
by another node such as the far-end media gateway. 


Enable path set-up (se): This local connection option is used to 
explicitly enable or disable the use of bearer signaling for path 
set-up.  Permitted values of this local connection option are "on" 
and "off". Examples of bearer signaling are SVC signaling, ITU 
Q.2630.1 signaling and combinations thereof. Examples of such 
combinations are the set-up of an AAL2 SVC and the assignment of a 
CID within it or the set-up of a concatenation of an AAL2 single-CID 
SVC and a CID channel within a multiplexed AAL2 VC. This parameter 
can be used with both the backward and forward bearer connection 


Kumar Informational [Page 4] 


RFC 3441 ATM MGCP Package January 2003 


set-up methods. In the former case, the call-terminating gateway 
sets up the bearer connection. In the latter case, the call- 
originating gateway sets up the bearer connection. 


This option may or may not be used in conjunction with atm/sc event 
notification. When this option and the atm/sc event notification are 
omitted, creating and modifying connection commands, the call agent 
is deferring any relevant decision to set up an ATM or AAL2 
connection to the media gateways. In the absence of this parameter, 
a media gateway’s autonomous decision to set up an ATM or AAL2 path 
via bearer signaling depends on default/provisioned behaviors, such 
as the applicability and nature (backward/forward) of a bearer 
connection set-up model, the network type ('nt'), connection type 
('atm/ct') and bearer type/VC ('atm/vc') local connection options, 
and the media gateway's awareness of whether it is the originating 
gateway or terminating gateway in a call. This awareness may be 
based on the presence or absence of an SDP remote connection 
descriptor in the initial create connection command. 


Connection Element Identifier (ci): This indicates the Virtual 
Circuit or CID to be used for the bearer connection. It is used when 
the call agent manages VC and/or CID resources in the bearer network. 


The ci parameter can be in one of the following formats: 


VCCI-«vcci» 

VCCI-«vcci»/CID-«cid» 
«ATMaddressType»-«ATMaddress»/VCCI-«vcci» 
«ATMaddress»/VCCI-«vcci» 
«ATMaddressType»-«ATMaddress»/VCCI-«vcci»/CID-«cid» 
«ATMaddress»/VCCI-«vcci»/CID-«cid» 
BCG-«bog»/VCCI-«vcci» 
BCG-«bcg»/VCCI-«vcci»/CID-«cid» 
BCG-«bcg»/VPI-«vpi»/VCI-«vci» 
BCG-«bog»/VPI-«vpi»/VCI-«vci»/CID-«cid» 
PORT-«portId»/VPI-«vpi»/VCI-«vci» 
PORT-«portId»/VPI-«vpi»/VCI-«vci»/CID-«cid» 
VPCI-«vpci»/VCI-«vci» 
VPCI-«vpci»/VCI-«vci»/CID-«cid» 
«ATMaddressType»-«ATMaddress»/VPCI-«vpci»/VCI-«vci» 
«ATMaddress»/VPCI-«vpci»/VCI-«vci» 
«ATMaddressType»-«ATMaddress»/VPCI-«vpci»/VCI-«vci»/CID-«cid» 
«ATMaddress»/VPCI-«vpci»/VCI-«vci»/CID-«cid» 


+ + X + + oo Xo F FF 6 0 0 Ro xo oo X 
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The subparameters of the ci parameter are defined as follows: 


Meaning | 
|-------------- | |---------------------------- | 
| vcci | VC connection Id | Decimal Integer 
| | | (16-bit equivalent) | 
|-------------- |----------------------- | ---------------------------- | 
cid Channel Id Decimal Integer 
(8-bit equivalent) 
|-------------- |----------------------- |" | 
|ATMaddressType| ATM address type | "NSAP", "E164", "GWID", | 
| | | "ALIAS" | 
|-------------- | |---------------------------- | 
| ATMaddress | ATM address | 40 hex digits ("NSAP") | 
upto 15 digits ("EI64") 
upto 32 chars ("GWID") 
| | | upto 32 chars ("ALIAS") | 
|-------------- |----------------------- |---------------------------- | 
| bcg |Bearer Connection Group| Decimal Integer | 
| | (8-bit equivalent) 
| vpi | Virtual Path Id | Decimal Integer 
| | | (8 or 12-bit equivalent) | 
|-------------- |----------------------- | ---------------------------- | 
| vci | Virtual Channel Id | Decimal Integer 
| | | (16-bit equivalent) | 
| portID | Port Id | Decimal Integer 
| | | (32-bit equivalent) | 
|-------------- |----------------------- |---------------------------- | 
| vpci | VP connection ID Decimal Integer 
| 
| 


| 
| (16-bit equivalent) 


The CID, or Channel ID, can refer to AAL1 as well as AAL2 
applications. In AAL1 applications based on [35], it refers to the 
octet position, starting from one, within an n x 64 SDT frame. 


The VPCI is a 16 bit field defined in Section 4.5.16 of ITU Q.2931. 
The VPCI is similar to the VPI, except for its width and the fact 
that it retains its value across VP crossconnects. 


The VCCI is a 16 bit field defined in ITU Recommendation Q.2941.2 


[14]. The VCCI is similar to the VCI, except for the fact that it 
retains its value across VC crossconnects. 
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In general, <vpci> and <vcci> values are unique between a pair of 
nodes. When they are unique between a pair of nodes, but not unique 
within a network, they need to be qualified at any node, by the ATM 
address of the remote node. These parameters can be pre-provisioned 
or signaled via SVC signaling messages. When VPCI and VCCI values 
are pre-provisioned, administrations have the option of provisioning 
them uniquely in a network. In this case, the ATM address of the far 
end is not needed to qualify these parameters. 


The <portId> parameter is used to identify the physical trunk port on 
an ATM module. It can be represented as a decimal or hex number of 
up to 32 digits. 


In some applications, it is meaningful to bundle a set of connections 
between a pair of ATM nodes into a bearer connection group. The 
<bcg> subparameter is an eight bit field that allows the bundling of 
up to 255 VPCs or VCCs. 


In some applications, it is necessary to wildcard some elements of 
the ci local connection option. The "S" wildcard character can be 
substituted for some of the terms of this parameter. While 
wildcarding, the constant strings that qualify the terms in the ci 
parameter are retained. The concatenation «ATMaddressType»- 
<ATMaddress> can be wildcarded in the following ways: 


* The entire concatenation, «ATMaddressType»-«ATMaddress», is 
replaced with a "$". 

* <ATMaddress> is replaced with a "$", but <ATMaddressType> is 
not. 


Examples of wildcarding the ci parameter in the AAL1 and AAL5 
contexts are: VCCI-$, BCG-100/VPI-20/VCI-$. 


Examples of wildcarding the ci parameter in the AAL2 context are: 
VCCI- 40/CID-$, BCG-100/VPI-20/VCI-120/CID-$. 


If the addressType is NSAP, the address is expressed in the standard 
dotted hex form. This is a string of 40 hex digits, with dots after 
the 2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th 
digits. The "Ox" prefix is not used, since this is always 
represented in hex. The last octet of the NSAP address is the 
'selector' field that is available for non-standard use. For 
example: 


L: atm/ci:NSAP-47.0091.8100.0000.0060.3e64.£d01.0060.3e64.£801.00/ 
VCCI-65 
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If the ATMaddressType is E164, the ATMaddress is expressed as a 
decimal number with up to 15 digits. For example: 

L: atm/ci:E164-9738294382/VCCI-100 


The E.164 numbers used can be in the International Format E.164 or 
conform to a private numbering plan. 


If the ATMaddressType is GWID, it means that the address is a Gateway 


Identifier or Node Alias. This may or may not be globally unique. 
In this format, the ATMaddress is expressed as an alphanumeric string 
("A"n-mAM, Ta Tetz "on MEM TOM UC HP S o ") " For example: 


L: atm/ci:GWID-officeABCmgx101lvism12 
The keyword "ALIAS" can be substituted for "GWID". For example: 
L: atm/ci:ALIAS-officeABCmgxlOlvism12 


An example of a GWID (ALIAS) is the CLLI code used for telecom 


equipment. For all practical purposes, it should be adequate for the 
GWID (ALIAS) to be a variable length string with a maximum size of 32 
characters. 


When an endpoint supporting the ATM package is audited for 
capabilities, the following local connection options from Section 3.1 
Shall be returned: connection type (atm/ct) and VC/bearer type 
(atm/vc). If more than one value is supported, these shall be 
expressed as a list of semicolon-separated values. Although this is 
not very useful, it is permissible for these values to have 
overlapping semantics (e.g., AAL1 and AAL1 SDT). An example of 
returning, in audit response, the local connection options defined in 
Section 3.1 is: 


A: atm/ct:AAL1 SDT;AAL2, atm/vc:PVC;CID 
3.2 ATM Adaptation Layer (AAL) 
These local connection options are used to parameterize the ATM 
adaptation layer (AAL). These are further classified as: generic AAL 
connection options, AAL1-related connection options and AAL2-related 


connection options. Currently, there are no local connection options 
defined in this category that pertain to AAL5. 
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TABLE 2: Generic Local Connection Options for the AAL 


4+--------- 4+--------------- 
| LCO | Meaning 
4+--------- 4+--------------- 
| aalApp | Application 

| | 

| | 

| | 

| | 

4+--------- 4+--------------- 
| sbc | Subchannel 

| | Count 
4+--------- 4+--------------- 


AAL application (aalApp): 

controlling standard for a 

adaptation layer. Other s 

to be prefixed with an "X- 
"Ytü-h323c7 


"af83" 


"AAL5 SSCOP" 


"itu i3661 unassured" 


"itu i3661 assured" 


"itu i3662" 


"tus13051" 


"itu i3652" 


Kumar 


4+--------------------------------------- + 


|itu h323c,af83,AAL5 SSCOP, | 
|itu_i3661_unassured, itu i3661 assured | 
|itu 13662, itu i3651, itu i3652, 

|itu 13653, itu i3654, | 
|FRF5, FRF8, FRF11,itu_h2221 | 


4+------------------------- = === + 

| 1...24 for Tl-based applications | 

| 1...31 for El-based applications | 
4--------------------------------------- t 
This connection option specifies the 

n application layer above the ATM 

trings can be defined. If used, these need 


Annex C of H.323 which specifies direct 
RTP on AAL5 [12]. 


af-vtoa-0083.001, which specifies 
variable size AAL5 PDUs with PCM voice 
and a null SSCS [13]. 


SSCOP as defined in ITU Q.2110 [14] 
running over an AAL5 CPS [27]. 

No information is provided regarding 
any layers above SSCOP such as Service 
Specific Coordination Function  (SSCF) 
layers. 


SSCS with unassured transmission, 
per ITU 1I.366.1 [11]. 


SSCS with assured transmission, 

per ITU I.366.1 [11]. This uses SSCOP 
[14]. 

SSCS per ITU I.366.2 [2]. 

Frame relay SSCS per ITU I.365.1 [15]. 
Service-specific coordination function, 
as defined in ITU 1I.365.2, for Connection 


Oriented Network Service (SSCF-CONS) 
[16]. This uses SSCOP [14]. 
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"itu 13659" Service-specific coordination function, 
as defined in ITU 1.365.3, for Connection 
Oriented Transport Service (SSCF-COTS) 
[17]. This uses SSCOP [14]. 


"itu i3654" Service-specific coordination function, 
as defined in ITU I.365.4 [28]. 


"FRE5" Use of the FRF.5 frame relay standard 
[23], which references ITU I.365.1 [15]. 


"FRE8" Use of the FRF.8 frame relay standard 
[24]. This implies a null SSCS and the 
mapping of the frame relay header 
into the ATM header. 


"FRF11" Use of the FRF.11 frame relay standard 
[25]. 
"itu h2221" Use of the ITU standard H.222.1 for 
audiovisual communication over AAL5 
[22]. 
Subchannel count (sbc): This parameter indicates the number of DSOs 
in ann x 64 connection. Such connections use an ATM adaptation 
layer 1 (ATM forum af-vtoa-78) or 2 (ITU I.366.2). For Tl-based 
applications, it can take on integral values in the inclusive range 
[1...24]. For El-based applications, it can take on integral values 
in the inclusive range [1...31]. When this parameter is omitted, the 


subchannel count must be known by other means. 


TABLE 3: Local Connection Options for AAL Type 1 


4+--------- 4+--------------- 4--------------------------------------- + 
| Lco | Meaning | Values 

4+--------- 4+--------------- 4--------------------------------------- + 
| pf | Partial fill | 1...48 | 
ae — — — —————— : 
| crt | Clock Recovery| NULL, SRTS, ADAPTIVE | 
| | Type | | 
4+--------- 4+--------------- 4--------------------------------------- + 
| fe | FEC enable | NULL, DELAY_SENSITIVE,LOSS_SENSITIVE | 
4+--------- 4+--------------- 4--------------------------------------- + 
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Partial Fill Count (pf): When present, the 'pf' parameter is used to 
indicate the fill level of cells. When this local connection option 
is absent, then other means (such as provisionable defaults) are used 
to determine the presence and level of partial fill. 


This parameter indicates the number of non-pad payload octets, not 
including any AAL SAR or convergence sublayer octets. For example, 
in some AAL1 applications that use partially filled cells with 
padding at the end, this attribute indicates the number of leading 
payload octets not including any AAL overhead. 


In general, permitted values of the pf parameter are integers in the 
range 1 - 48 inclusive. However, this upper bound is different for 
different adaptations since the AAL overhead, if any, is different. 
If a specified partial fill (e.g. 47) is greater than or equal to the 
maximum fill (in this example, 46 for AAL1 P-cells), then complete 
fill (46 in this example) is used. Using a 'partial' fill of 48 
effectively disables partial fill. Values below or above the 
permissible range of 1-48 MUST be rejected with an error code of 532 
{Unsupported value(s) in LocalConnectionOptions}. 


In the AAL1 context, this parameter applies uniformly to both P and 
non-P cells. In AAL1 applications that do not distinguish between P 
and non-P cells, a value of 47 indicates complete fill (i.e., the 
absence of partial fill). In AAL1 applications that distinguish 
between P and non-P cells, a value of 46 indicates no padding in 
P-cells and a padding of one in non-P cells. 


If partial fill is enabled (i.e., there is padding in at least some 
cells), then AAL1 structures must not be split across cell 
boundaries. These shall fit in any cell. Hence, their size shall be 
less than or equal to the partial fill size. Further, the partial 
fill size is preferably an integer multiple of the structure size. 

If it is not, then the partial fill size stated in the local 
connection options shall be truncated to an integer multiple of the 
structure size (e.g., a partial fill size of 40 is truncated to 36 to 
support six 6 x 64 channels). 


Clock recovery type (crt): This is used in AAL1 UDT (unstructured 
data transfer) applications only. It can be assigned the values: 
"NULL", "SRTS", or "ADAPTIVE". A value of "NULL" is equivalent to 


omitting this parameter and implies that the stream (T1 or El) 
encapsulated in ATM is either synchronous to the ATM network or is 


re-timed, before AAL1 encapsulation, via slip buffers. The default 
value used in the absence of this LCO can be hardcoded or 
provisioned. 
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Forward Error Correction Enable (fe): This indicates whether FEC, as 
defined in ITU I.363.1 [1], is enabled or not. Possible values are: 
"NULL", "DELAY SENSITIVE" and "LOSS_SENSITIVE". FEC can be enabled 


differently for delay-sensitive and loss-sensitive connections. A 
"NULL" value implies disabling FEC for an AAL1 connection. 


TABLE 4: Local Connection Options for AAL Type 2 


4--------- 4--------------- 4R--------------------------------------- + 
| eo | Meaning | Values 

4+--------- 4--------------- 4--------------------------------------- + 
| pfl | Profile List | See below 

eee oe Peete eee ee! 
| smplCPS | Simplified CPS | on, off 

| | [21] | | 
4+--------- 4+--------------- 4--------------------------------------- + 
| tmcu | Combined use | Integer microseconds | 
| | timer | (32-bit equivalent) 

+--------- +--------------- 4--------------------------------------- + 
| aalsap |Service access | AUDIO, MULTIRATE 

| | point | | 
4+--------- 4+--------------- 4--------------------------------------- + 
| cktmd | Circuit mode | on, off 

oe es alate — ee 
| frmd | Frame mode | on, off 

| | enable | | 
+--------- +--------------- 4--------------------------------------- + 
| genpem | Generic PCM | PCMA, PCMU | 
| | setting | | 
+--------- +--------------- 4--------------------------------------- + 
| ted | Transmission | on,off 

| [error detection | | 
+--------- +--------------- 4+--------------------------------------- + 
|rastimer | SSSAR | | 
| | reassembly | Integer microseconds 

| | timer | (32-bit equivalent) 

+--------- +--------------- 4--------------------------------------- + 


Profile List (pfl): This is a list of profiles. Profile types are 
followed by profile numbers for each type. The ordering of profiles 
can imply preference, with the most preferred profile first. There 
can be multiple instances of the same profile type in this list. 
Spaces are used as delimiters within this list. Therefore, to comply 
with MGCP syntax [36], it is necessary to enclose this list in double 
quotes. 
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The format of the pfl parameter is as follows: 


"<profileType#1><format list#1><profileType#2><format list#2> 
<profileType #M><format list#M>" 


where «format list#i> has the form <profile#i_1l>...<profile#i_N> 


The <profileType> parameter indicates the type of profile. It is 
expressed in the format AAL2/<profileClass> where <profileClass> 
identifies the source of the definition of the profile. 


The <profileClass> can be assigned a string value indicating the 
source of the subsequent profile numbers until the next <profileType> 
field. The following rules apply to the contents of the 
<profileClass> field: 


- <profileClass> = "ITU" indicates profiles defined by ITU. 
Examples: profiles defined in the 1.366.2 specification [2]. 
- <profileClass> = "ATMF" indicates profiles defined by ATM 


forum. Examples: profiles defined in af-vtoa-0113 [3] or af- 
vmoa-0145.000 [21]. 

- <profileClass> = "custom" indicates profiles defined by a 
corporation or a multi-vendor agreement. Since there is no 
standard administration of this convention, care should be 
taken to preclude inconsistencies within the scope of a 


deployment. 

- <profileClass> = <corporateName> 
An equipment vendor or service provider can use its registered, 
globally unique corporate name (e.g., Cisco, Telcordia etc.) as 


a string value of the <profileClass>. It is suggested that 
organizations maintain consistent definitions of the advertised 
AAL2 profiles that bear their corporate name. 

- The <profileClass> can be based on IEEE Standard 802-1990, 
Section 5.1, which defines the globally unique, IEEE- 
administered, three-octet OUIs used in MAC addresses and 
protocol identifiers. In this case, the <profileClass> field 
shall be assigned a string value of "IEEE:" concatenated with 
«oui» where «oui» is the hex representation of a three-octet 
field identical to the IEEE OUI. Since this is always 
represented in hex, the "Ox" prefix is not used. Leading zeros 
may be omitted. For example, "IEEE:00000C" and "IEEE:C" both 
refer to Cisco Systems, Inc. 


The «profiles» parameter is expressed as a decimal number in the 
range 1-255. 
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An example of the use of the pfl parameter is: 
L: atm/pfl:"AAL2/ITU 8 AAL2/ATMF 7 8 AAL2/custom 100 AAL2/cisco 200" 


The syntax for pfl can be represented compactly in the following ABNF 
(RFC2234) form: 


pfl = "%Sx22" 1* (profileType (1*profile#))"%x22" 
profileType = "AAL2/" profileClass space 
profile# = 1-255 space ; decimal integer followed by space 
profileClass = 

"ATMF"/"ITU"/"custom"/corporateName/("IEEE:" oui) 
corporateName = 1*ALPHA ;one or more alphanumeric characters 
oui = 1*6 HEXDIG; 1-6 hex digits per IEEE Standard 802-1990 


space = %d32 


Simplified CPS (smplCPS): This enables the AAL2 CPS simplification 
described in [21]. It can be assigned the following values: on, off. 
Under this simplification, each ATM cell contains exactly one AAL2 
packet. If necessary, octets at the end of the cell are padded with 
zeros. 


AAL2 combined use timer (tmcu): This is defined in ITU 1.363.2 [10]. 
It is an integer number of microseconds, represented as the decimal 
equivalent of 32 bits. 


AAL service access point (aalsap): The service access point for AAL2 
is defined in ITU 1.366.2 [2]. The aalsap local connection option 
can take on the following string values: AUDIO, MULTIRATE. 


Circuit mode (cktmd): This is used to enable circuit mode data [2]. 
It can be assigned a value of "on" or "off". 


Frame mode (frmd): This is used to enable frame mode data [2]. It 
can be assigned a value of "on" or "off". 


Generic PCM setting (genpcm): This indicates whether generic PCM 
encoding in AAL2 profiles is A-law or Mu-law. It can be assigned the 
string values of "PCMA" and "PCMU". 


Transmission error detection (ted): Transmission error detection is 
defined in ITU I.366.1 [11]. The ted local connection option can 
take on the following values: on, off. This local connection option 
is useful in qualifying the aalApp local connection option, when the 
value of the latter is "itu i3661 unassured". 
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SSSAR reassembly timer (rastimer): This is defined in ITU 1I.366.1 
[11]. It is an integer number of microseconds, represented as the 
decimal equivalent of 32 bits. 


When an endpoint supporting the ATM package is audited for 
capabilities, the following local connection options from Section 3.2 
shall be returned: application (atm/aalApp). Further, if one of the 
values atm/ct is "AAL2", the following additional local connection 
options shall be returned: profile list (atm/pfl), simplified CPS 
(atm/smplCPS), service access point (atm/aalsap), circuit mode 
enable(atm/cktmd), frame mode enable (atm/frmd) and generic PCM 
setting (atm/genpcm). If more than one value is supported, these 
shall be expressed as a list of semicolon-separated values. For 
atm/smplCPS, atm/cktmd and atm/frmd, an audit can return "on", "off" 
or "on;off" depending on whether the mode is mandatory, unsupported 
or optional for the endpoint. 


An example of returning, in audit response, the local connection 
options defined in Section 3.2 is: 


A: atm/aalApp:itu i3662, atm/pfl:"AAL2/ATMF 7 8", smplCPS:on;off, 
aalsap:MULTIRATE, cktmd:off, frmd:off, genpcm:PCMU;PCMA 


3.3 Service Layer 


TABLE 5: Local Connection Options for the Service Layer 


4-------------- 4--------------- 4--—-------------------------------- * 
| Lco | Meaning | Values 

teoe Sanaa Sea {SSS Seaosess=s5 4---------------------------------- * 
| vsel | Voice codec | See below 

| | Selection | | 
E A TE A EE toes ee ee oe ee + 
| dsel | Data codec | See below 

| | Selection | | 
pa atnan E E 4--—-------------------------------- * 
| fsel | Fax codec | See below 

| | Selection | | 
4-------------- 4--------------- 4--—-------------------------------- * 
| conf | Codec | Even number (4 - 32) hex digits | 
| | Configuration | 

E EE AERONA EEE hee E a ee + 
| usi | ISUP User | Two hex digits 

| | Information | | 
qeusepeeecceeu dXneuneeeeme T peescepsteeeeeeeeeeree ecce * 
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Voice codec selection (vsel): This is a prioritized list of one or 
more 3-tuples describing voice service. Each vsel 3-tuple indicates 
a codec, an optional packet length and an optional packetization 
period. 


The vsel local connection option is structured as follows: 


"<encodingName #1> <packetLength #1><packetTime #1> 
<encodingName #2> <packetLength #2><packetTime #2> 


<encodingName #N> <packetLength #N><packetTime #N>" 
where the <encodingName> refers to a codec name such as PCMU, G726- 


32, G729 etc. See [18] and [34] for a list of codecs with static 
payload types. The «packetLength» is a decimal integer 


representation of the packet length in octets. The «packetTime» is a 
decimal integer representation of the packetization interval in 
microseconds. 

Voiceband data codec selection (dsel): This is a prioritized list of 


one or more 3-tuples describing voiceband data passthrough service. 
Each dsel 3-tuple indicates a codec, an optional packet length and an 
optional packetization period. Depending on the application, the 
dsel local connection option may or may not cover facsimile service. 
This is indicated via an <fxIncl> flag preceding the list of 3- 
tuples. This flag indicates whether the dsel list explicitly 
addresses facsimile ("on" value) or not ("off" value). This flag can 
also be set to "-", which is equivalent to setting it to "off". 


If <fxIncl> is "on", then it is rarely useful to also include an fsel 
option. However, it is syntactically correct to do so as long as the 
dsel and fsel options include an identical set of 3-tuples, perhaps 
in a different order. 


If <fxIncl> is "off", then any fsel list may still be ignored if the 
media gateway does not provide separate treatment of voiceband data 
passthrough and fax. Since, in this case, there is no distinct 
facsimile service from the media gateway's perspective, any fsel list 
does not apply. 


The dsel local connection option is structured as follows: 


"<fxIncl> «encodingName 41» «packetLength #1><packetTime £41» 
«encodingName 42» «packetLength #2><packetTime #2> 


<encodingName £N» «packetLength #N><packetTime #N>" 
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where the <encodingName> refers to a codec name such as PCMU, G726- 
32, G729 etc. The «packetLength» is a decimal integer representation 
of the packet length in octets. The «packetTime» is a decimal 
integer representation of the packetization interval in microseconds. 


Facsimile codec selection (fsel): This is a prioritized list of one 
or more 3-tuples describing fax service. Each fsel 3-tuple indicates 
a codec, an optional packet length and an optional packetization 
period. If the dsel option includes facsimile, the fsel connection 
option should be consistent with it. Each fsel 3-tuple indicates a 
codec, an optional packet length and an optional packetization 
period. The fsel local connection option is structured as follows: 


"<encodingName #1> «packetLength #1><packetTime 41» 
<encodingName #2> <packetLength #2><packetTime #2> 


<encodingName #N> <packetLength #N><packetTime #N>" 
where the <encodingName> refers to a codec name such as PCMU, G726- 
32, G729 etc. The <packetLength> is a decimal integer representation 
of the packet length in octets. The «packetTime» is a decimal 


integer representation of the packetization interval in microseconds. 


Since spaces are used as delimiters within the vsel, dsel and fsel 
lists, it is necessary to enclose these lists in double quotes [36]. 


The vsel, fsel and dsel parameters complement the rest of the local 
connection options and should be consistent with them. 


Examples of the use of these parameters are: 


L: atm/vsel:"G729 10 10000 G726-32 40 10000" 

L: atm/dsel:"off PCMA 10 10000 G726-32 40 10000" 

L: atm/fsel:"PCMU 40 5000 G726-32 20 5000" 

L: atm/vsel:"G729 10 10000 G726-32 40 10000" 

L: atm/dsel:"on PCMA 10 10000 G726-32 40 10000" 
The «packetLength»and «packetTime» can be set to "-" when not needed. 
A «fxIncl» value of "-" is equivalent to setting it to "off". For 
example: 

L: atm/vsel:"G729 - - G726-32 - -" 

L: atm/dsel:"- G729 - - G726-32 - -" 


L: atm/fsel:"G729-24 - -" 
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The vsel, dsel and fsel local connection options can be used in the 
AAL1, AAL2 and AAL5 contexts. The <packetLength> and <packetTime> 
are not meaningful in the AAL1 case and should be set to "-". In the 
AAL2 case, these local connection options indicate the preferred use 
of some or all of the rows in a given profile table. If multiple 3- 
tuples are present, they can indicate a preferentially ordered 
assignment of some rows in that profile to voice, voiceband data 
passthrough or facsimile service (e.g., row A preferred to row B 
etc). If multiple profiles are specified in the pfl parameter 
(described in section 3.2), the profile qualified by these local 
connection options is the first profile in the list. 


Codec configuration (ccnf): This is used to convey the contents of 
the single codec information element (IE) defined in [30]. The 
contents of this IE are: a single-octet Organizational Identifier 
(OID) field, followed by a single-octet Codec Type field, followed by 
zero or more octets of a codec configuration bit-map. The semantics 
of the codec configuration bit-map are specific to the 
organization[30, 31]. Since this bit-map is always represented in 
hex format, the "Ox" prefix is omitted. Leading zeros are not 
omitted. For example: 


L: atm/ccnf:01080C 


indicates an Organizational Identifier of 0x01(the ITU-T). Using 
[57], the second octet (0x08) indicates a codec type of G.726 
(ADPCM). The last octet, 0x0C indicates that 16 kbps and 24 kbps 
rates are NOT supported, while the 32 kbps and 40 kbps rates ARE 
supported. 


ISUP User Information (usi): This is used to convey the contents of 
the 'User Information Layer 1 protocol' field within the bearer 
capability information element defined in Section 4.5.5 of [32], and 
reiterated as the user service information element (IE) in Section 
3.57 of [33]. The 'User Information Layer 1 protocol' field consists 
of the five least significant bits of Octet 5 of this information 
element. 


The usi LCO represented as a string of two hex digits. The "Ox" 
prefix is omitted since this value is always hexadecimal. These hex 
digits are constructed from an octet with three leading ’0’ bits and 
the last five bits equal to the 'User Information Layer 1 protocol' 
field described above. Digits to the left are more significant than 
digits to the right. The resulting values of the usi local 
connection option are as follows: 
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VALUE MEANING 


0x01 CCITT standardized rate adaption V.110 and X.30 
0x02 Recommendation G.711 Mu-law 
0x03 Recommendation G.711 A-law 
0x04 Recommendation G.721 32 kbps ADPCM 
and Recommendation I.460 
0x05 Recommendations H.221 and H.242 
0x06 Recommendation  H.223 and H.245 
0x07 Non-ITU-T standardized rate adaption 
0x08 ITU-T standardized rate adaption V.120 
0x09 CCITT standardized rate adaption X.31 HDLC flag stuffing 


3.4 ATM Bearer Traffic Management 


These local connection options are used to convey ATM traffic 
parameters. 


TABLE 6: Local Connection Options for ATM bearer traffic management 


4R-—------- R-—------------- Fon E A NA AE E + 

| ATM Lco | Meaning | Values | 

+--------- +--------------- ln" a ae E ee EE + 
atc ATM transfer CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR, 

capability or |DBR,SBR,ABT/IT,ABT/DT 

| | service | | 

| | category | | 

+--------- +-—-------------- tan = + 

| sbt |atc subtype ldem 

4R-—------- R-—------------- tan E T E A + 

| qos | QoS class [5022485 

4R--------- R-—------------- tan E A a A S + 

| bcob | Broadband | 20 3d 

| |Connection | (Defined values listed below) 

| |-Oriented | | 

| |Bearer Class | | 

+--------- 4+--------------- Fann E A T E A + 

| eetim  |End-to-end |on, off 

| [timing required| | 

+--------- +--------------- tee SSS HS ae eS a ese ene ae Se eae eee + 

| ste |Susceptibility | 0...3 

| [to clipping | (Defined values listed below) 

4R-—------- R-—------------- tan E A E A S + 

| upcc |User plane 0...3 

| | connection | (Defined values listed below) 

| |configuration | | 

+--------- 4+--------------- tan A E E E + 
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ATM transfer capability (atc): This parameter indicates the ATM 
Transfer Capability described in ITU I.371 [19], equivalent to the 
ATM Service Category described in the UNI 4.1 Traffic Management 
Specification [8]. In applications conforming to ITU I.371, this 
parameter can be assigned the following values: DBR, SBR, ABT/IT, 
ABT/DT, ABR. In applications conforming to the UNI 4.1 Traffic 
Management specification, this parameter can be assigned the 
following values: CBR, nrt-VBR, rt-VBR, UBR, ABR, GFR. 


Subtype (sbt): This qualifies the atc local connection option. It 
can be assigned integer values of 1...5. The following combinations 
of the atc and sbt local connection options are meaningful: 


atc sbt Resulting transport 
CBR/DBR Y Voiceband signal transport (ITU G.711, G.722, I.363) 
CBR/DBR 2 Circuit transport (ITU I.363) 
CBR/DBR 4 High-quality audio signal transport (ITU I.363) 
CBR/DBR 5 Video signal transport (ITU I.363) 
nrt-VBR 1 nrt-VBR.1 
nrt-VBR 2 nrt-VBR.2 
nrt-VBR 3 nrt-VBR.3 
rt-VBR 1 rt-VBR.1 
rt-VBR 2 rt-VBR.2 
rt-VBR 3 rt-VBR.3 
UBR 1 UBR.1 
UBR 2 UBR.2 
GFR aL GFR.1 
GFR 2 GRR.2 
SBR 1 SBR1 
SBR 2 SBR2 
SBR 3 SBR3 
Subtypes for the atc values of CBR or DBR are per [29]. Subtypes for 


the remaining atc values are per [8] and [19]. 
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QoS class (gos): This indicates the QoS class specified in ITU 
I.2965.1 [4]. It can take on the integer decimal values in the range 
0-5. These values are mapped into QoS classes as follows: 
ERE vang | é‘C;C‘CS;S MEANING | 
QN CMM (en Default QoS — | 
Eo a3 +4 Steangent o | 
lh i MEE mine c etr Ue 
MEE NINE MEL Bupeguph no e EE vg 
MEN CNN INN o MEER 
i >. 29... I. .leEMasehb ic eveR a] 


Broadband Connection-Oriented Bearer Class (bcob): The bcob local 
connection option indicates the Broadband Connection-Oriented Bearer 
Class specified in ITU Q.2961.2 [5]. It is represented as a decimal 
number in the range 0 - 31, or its hex equivalent (range 0x0 - OxlF). 
The following values are currently defined: 


| VALUE | MEANING | 
E ME RAT BcOB-A | 
EEME NONEM MEN BcoB-c | 
| 5 | Frame relaying bearer service | 
ii. ae MINE BOB-X ss 
ME 24 | BCOB-VP (transparent VP service) | 


End-to-end timing (eetim): This indicates whether end-to-end timing 
is required (Table 4-8 of [29]). It can be assigned a value of "on" 
or "off". 
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Susceptibility to clipping (stc): The stc local connection option 
indicates susceptibility to clipping. It is represented as a decimal 
number in the range 0 - 3, or its hex equivalent (range 0x0 - 0x3). 


All values except those listed below are reserved. 


| VALUE | MEANING | 

| 0 | Not susceptible to clipping 

| 1 | Susceptible to clipping 
User plane connection configuration (upcc): The upcc local connection 
option is represented as a decimal number in the range 0 - 3, or its 
hex equivalent (range 0x0 - 0x3). All values except those listed 


below are reserved. 


| VALUE | MEANING | 
| 0 | Point to point 
| i | Point to multipoint 


ATM QoS parameters, forward direction (aqf) and backward direction 
(aqb): Here, forward is the direction away from the media gateway, 
backward is the direction towards the gateway. If the directional 
convention used by bearer signaling at the gateway is different, then 
appropriate translations must be done by the media gateway. These 
parameters have the following format: 


"<cdvType><acdv><ccdv><eetd><cmtd><aclr>" 


Since spaces are used in this list, it must be enclosed in double 
quotes for MGCP compliance [36]. 


The <cdvType> parameter can take on the string values of "PP" and 
"2P". These refer to the peak-to-peak and two-point CDV as defined 
in UNI 4.0 [6] and ITU Q.2965.2 [7] respectively. 


The CDV parameters, <acdv> and <ccdv>, refer to the acceptable and 
cumulative CDVs respectively. These are expressed in units of 
microseconds and represented as the decimal or hex equivalent of 24- 
bit fields. These use the cell loss ratio, <aclr>, as the "alpha" 
quantiles defined in the ATMF TM 4.1 specification [8] and in ITU 
E396: [9] 
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The transit delay parameters, <eetd> and <cmtd>, refer to the end-to- 
end and cumulative transit delays respectively in milliseconds. 

These are represented as the decimal equivalents of 16-bit fields. 
These parameters are defined in Q.2965.2 [7], UNI 4.0 [8] and Q.2931 
[29]. 


The <aclr> parameter refers to forward and backward acceptable cell 
loss ratios. This is the ratio between the number of cells lost and 
the number of cells transmitted. It is expressed as the decimal or 
hex equivalent of an 8-bit field. This field expresses an order of 
magnitude n, where n is an integer in the range 1-15. The Cell Loss 
Ratio takes on the value 10 raised to the power of minus n. 


If any of these parameters is not specified, is inapplicable or is 
implied, then it is set to "-". 


Examples of the use of the aqf and aqb local connection options are: 


L: atm/aqf:"PP 8125 3455 32000 - 11" 
L: atm/aqb:"PP 4675 2155 18000 - 12" 


This implies a forward acceptable peak-to-peak CDV of 8.125 ms, a 
backward acceptable peak-to-peak CDV of 4.675 ms, forward cumulative 
peak-to-peak CDV of 3.455 ms, a backward cumulative peak-to-peak CDV 
of 2.155 ms, a forward end-to-end transit delay of 32 ms, a backward 
end-to-end transit delay of 18 ms, an unspecified forward cumulative 
transit delay, an unspecified backward cumulative transit delay, a 
forward cell loss ratio of 10 raised to minus 11 and a backward cell 
loss ratio of 10 to the minus 12. 


ATM traffic descriptors, forward direction CLP=0+1 (adf0+1), backward 
direction CLP=0+1 (adb0+1), forward direction CLP=0 (adf0), backward 
direction CLP=0 (adb0): Here, forward is the direction away from the 
media gateway, backward is the direction towards the gateway. If the 
directional convention used by bearer signaling at the gateway is 
different, then appropriate translations must be done by the media 
gateway. The adf0+1, adb0+1, adf0 and adbO local connection options 
have the following format: 


"<pcr><scr><mbs><cdvt><mcr><mfs><fd><te>" 


Since spaces are used in these lists, they must be enclosed in double 
quotes for MGCP compliance [36]. 


These parameters are defined per the ATMF TM 4.1 specification [8]. 


Each of these parameters can be set to "-" if the intent is to not 
Specify it via MGCP. These definitions are listed briefly in Table 7 
below. 
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TABLE 7: ATM Traffic Descriptor Parameters 


PARAMETER MEANING UNITS 
pcr Peak Cell Rate Cells per second 
scr Sustained Cell Rate Cells per second 
mbs Maximum Burst Size Cells 
cdvt Cell Delay Variation Tolerance Microseconds 
mcr Minimum Cell Rate Cells per second 
mfs Maximum Frame Size Cells 
fd Frame Discard Allowed on/off 
te CLP tagging enabled on/off 


The pcr, scr, cdvt and mbs can be represented as the decimal 
equivalents of 24-bit fields. The mbs and mfs can be represented as 
the decimal equivalents of 16-bit fields. 


Examples of these local connection options are: 


L: atm/adf0+1:"200 100 20 ---on -", 
atm/adf0:"200 80 15 ---- off", 
atm/adb0+1:"200 100 20 --- on -", 
atm/adb0:"200 80 15 --- - off" 


This implies a forward and backward PCR of 200 cells per second for 
all cells regardless of CLP, forward and backward PCR of 200 cells 
per second for cells with CLP=0, a forward and backward SCR of 100 
cells per second for all cells regardless of CLP, a forward and 
backward SCR of 80 cells per second for cells with CLP=0, a forward 
and backward MBS of 20 cells for all cells regardless of CLP, a 
forward and backward MBS of 15 cells for cells with CLP=0, an 
unspecified CDVT which can be known by other means, and an MCR and 
MFS which are unspecified because they are inapplicable. Frame 
discard is enabled in both the forward and backward directions. 
Tagging is not enabled in either direction. 


ABR parameters, forward direction (abrf) and backward direction 
(abrb): Here, forward is the direction away from the media gateway, 
backward is the direction towards the gateway. If the convention 
used by bearer signaling at the gateway is different, then 
appropriate translations must be done by the media gateway. The abrf 
and abrb local connection options have the following format: 


"<nrm><trm><cdf><adtf>" 


Since spaces are used in these lists, they must be enclosed in double 
quotes for MGCP compliance [36]. 
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These ABR parameters are defined per [6] and [8]. Their definition 
is summarized in Table 8 below. In MGCP, these are represented as 

the decimal equivalent of the binary fields mentioned below. If any 
of these parameters is meant to be left unspecified, it is set to "- 


TABLE 8: ABR Parameters 


p----------- R------------------2---2------------ R----------------------- + 

| PARAMETER | MEANING | FIELD SIZE | 

4+—----------- +—--------------------------------- 4+----------------------- + 

| NRM | Maximum number of cells per | 3 bits 

| | forward Resource Management cell| 

p----------- 4--------------------------------- 4----------------------- t 

| TRM | Maximum time between | 3 bits 

| [forward Resource Management cells| 

p----------- p-------------2-------------------- 4----------------------- t 

| CDF | Cutoff Decrease Factor | 3 bits 

+----------- +------------------------- === 4+—----------------------- + 

| ADTF | Allowed Cell Rate Decrease | 10 bits 

| | Time Factor | | 

4+----------- +—--------------------------------- 4+----------------------- + 
ABR set-up parameters (abrSetup): This local connection option is 
used to indicate the ABR parameters needed during call/connection 
establishment (Section 10.1.2.2 of the UNI 4.0 signaling 
specification [6]). The abrSetup local connection option has the 
following format: 

"<ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf>" 

Since spaces are used in this list, it must be enclosed in double 
quotes for MGCP compliance [36]. 
These parameters are defined per [6]. Their definitions are listed 
briefly in Table 9 below. In these definitions, forward is the 
direction away from the media gateway, backward is the direction 
towards the gateway. If the convention used by bearer signaling at 
the gateway is different, then appropriate translations must be done 
by the media gateway. If any of these parameters is meant to be left 


unspecified, it is set to "-". 
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TABLE 9: ABR Set-up Parameters 


portan $i SS SS SS SS e SSS SS 
| PARAMETER | MEANING 

4R----------- 4--—-------------------------------- 
| <ficr> | Forward Initial Cell Rate 

| | (Cells per second) 

4----------- tS Sep Hap eae ae ee a 
| <bicr> | Backward Initial Cell Rate 

| | (Cells per second) 

prerano 4--—-------------------------------- 
| «ftbe» | Forward transient buffer 

| | exposure (Cells) 

prinsi St a omg aoa aa E 
| <btbe> | Backward transient buffer 

| | exposure (Cells) 

posata 4---------------------------------- 
| <crmrtt> | Cumulative RM round-trip time 

| | (Microseconds) 

TT - 4--—-------------------------------- 
| «frif» | Forward rate increase factor 

| | (used to derive cell count) 
4----------- to S SSS Sa eae a Sear SS ee Sao 
| <brif> | Backward rate increase factor 

| | (used to derive cell count) 

to--- 7777-7 4--—-------------------------------- 
| <frdf> | Forward rate decrease factor 

| | (used to derive cell count) 
t----- 7-7-7 hae SS E 
| <brdf> | Backward rate decrease factor 

| | (used to derive cell count) 

press enese a E 


3.5 AAL Dimensioning 


The Local Connection Options in Table 10 are 
operation of the AAL. In these parameters, 
away from the media gateway. Backward is th 
media gateway. These parameters are represe 
in the ranges listed in Table 10. 


January 2003 


Decimal equivalent | 
of 24-bit field | 


| Decimal equivalent | 
| of 24-bit field | 


| Decimal equivalent | 
| of 24-bit field | 


| Decimal equivalent | 
| of 24-bit field | 


| Decimal equivalent | 
| of 24-bit field | 


4--------------------- + 
| Decimal integer | 
| 0 -15 | 
4--------------------- * 
| Decimal integer | 
| 0 -15 | 
4--------------------- * 
| Decimal integer | 
| 0 -15 | 
4--------------------- * 
| Decimal integer | 
| 0 -15 | 
4--------------------- - 


used to dimension the 
forward is the direction 
e direction towards the 
nted as decimal integers 


TABLE 10: Local Connection Options used to dimension the AAL 


$ecc————- 4--------------- qoccccfee- er 

| rco | Meaning | Values (Decimal 

Foucelsee- 4--------------- 4----------------- 

| str | Structure | d 65,535 

| | Size | 

parisi 4--------------- 4----------------- 
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[size 
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4--------- 4--------------- 4--------------------------------------- * 
[bsscopuu |Backward | 1-65,524 

maximum SSCOP 

UU size 
4--------- 4--------------- 4--------------------------------------- + 


Structured Data Transfer Block Size (str): This parameter is 
meaningful only when structured AAL1 is used. It indicates the size 
(in octets) of the block used for structured data transfer. If not 
included as a local connection option, the structure size is to be 
known by other means. For instance, af-vtoa-78 [20] fixes the 
structure size for n x 64 service, with or without CAS. The 

L: atm/str parameter is coded as the decimal equivalent of a 16-bit 
field [29]. The theoretical maximum value of this parameter is 
65,535, although most services use much less. 


CBR Rate (cbrRate): This is a hexadecimal representation of the bit 
map defined in Table 4-6 of ITU 9.2931 [29]. This is represented as 
exactly two hex digits. For example: 


L: atm/cbrRate:04 
implies a CBR rate of 1.544 Mbps. 


Forward maximum CPCS-SDU size (fcpcs): This is the maximum size of 
the AAL2 or AA5 CPCS SDU in the forward direction. 


Backward maximum CPCS-SDU size (bcpcs): This is the maximum size of 
the AAL2 or AA5 CPCS SDU in the backward direction. 


Forward maximum AAL2 CPCS-SDU rate (fSDUrate): This is the maximum 
rate of the AAL2 CPCS-SDUs in the forward direction. 


Backward maximum AAL2 CPCS-SDU rate (bSDUrate): This is the maximum 
rate of the AAL2 CPCS-SDUs in the backward direction. 


The fSDUrate and bSDUrate local connection options can be used to 
rate-limit AAL2 CIDs, especially when used in the SSSAR [1] and frame 
mode [2] contexts. 


Forward maximum frame mode block size (ffrm): This is the maximum 
Size, in the forward direction, of the AAL2 frame mode data unit 
(I.366.2) [2]. 

Backward maximum frame mode block size (bfrm): This is the maximum 
Size, in the backward direction, of the AAL2 frame mode data unit 
(I.366.2) [2]. 
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Forward maximum SSSAR-SDU size (fsssar): This is the maximum size, in 
the forward direction, of the AAL2-based SSSAR-SDU (1.366.1) [1]. 


Backward maximum SSSAR-SDU size (bsssar): This is the maximum size, 
in the backward direction, of the AAL2-based SSSAR-SDU (1.366.1) [1]. 


Forward maximum SSCOP-SDU size (fsscopsdu): This is the maximum size, 
in the forward direction, of the AAL2-based SSCOP-SDU (1I.366.1) [1]. 


Backward maximum SSCOP-SDU size (bsscopsdu): This is the maximum 
Size, in the backward direction, of the AAL2-based SSCOP-SDU 


(12966-1). TT]: 

Forward maximum SSCOP-UU size (fsscopuu): This is the maximum size, 
in the forward direction, of the AAL2-based SSCOP-UU field(I.366.1) 
pli, 


Backward maximum SSCOP-UU size (bsscopuu): This is the maximum size, 
in the backward direction, of the AAL2-based SSCOP- UU field 
(I.366.1) [1]. 


4.0 Signals and Events 


Standard MGCP syntax and keywords [36] are used in Table 11 to define 
the events in this package. Since these are all connection events, 
they cannot be requested for endpoints. For consistency with MGCP 
[36], it is required that the suffix @<connection-id> NOT be omitted 
even if there is only one connection to an endpoint. This suffix can 
also be wildcarded per MGCP rules. 


There are no auditable event-states associated with the ATM package. 
Set-up complete ("sc"): 


Within the RequestedEvents (R:) structure, "sc" is used to request 
notification of successful ATM or AAL2 connection set-up. The ATM OR 
AAL2 bearer path is ready for subscriber payload carriage when this 
notification is sent. 


This could be the set-up of an SVC, the assignment of an AAL2 CID 
path and combinations thereof. Examples of such combinations are the 
set-up of an AAL2 SVC and the assignment of a CID within it or the 
set-up of a concatenation of an AAL2 single-CID SVC and a CID channel 
within a multiplexed AAL2 VC. 


This event is included for backward compatibility. It is preferred 


that the call agent and the media gateway rely on provisional 
acknowledgements in the case in which connection set-up has a long 
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latency. However, if this event is requested, the media gateway must 
issue notification of connection set-up via this event. In this 
case, a provisional acknowledgement is not very useful, and full 
acknowledgement of the create connection or modify connection need 
not be deferred until connection set up. 


The designated trigger for an ATM OR AAL2 connection set-up is an 
"on" value of the L: atm/se local connection option provided with a 
create or modify connection command. However, it is recognized that 
certain applications use the presence of an atm/sc event notification 
to initiate the set-up of an ATM or AAL2 connection. 


TABLE 11: Signals and Events in the ATM 


Bearer path set-up 
complete 


Bearer path set-up 
failed 

Enable CAS via 
type 3 packets 


Enable DTMF tone 
forwarding via 


p 
| 
| 
| 
| 
| 
| 
| 
| 

packets | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 

| 

| 

| 

| 

| 

| 

| Enable MF tone 
| | forwarding via 

| packets 

| 

| 

| 

| 

| 

| 

| 

| 


Enable MF-R1 tone 
forwarding via 
packets 


Enable MF-R2 tone 
forwarding via 
packets 


Used codec changed 
to codec named by 
the string 


Packetization period 
changed to 4 
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Loss of connectivity 
with reason code # 


| | | | 
| pftrans (#) | Profile element [| Ge d | 
| | changed to row # | | | | 
| cle (4) | Cell Loss li «ed | | 
| | threshold (# ) | | | | 
| | exceeded | | | | 
|--------------- |----------------------- m | 

pl (#) Packet Loss Threshold C 
exceeded (# ) 

|--------------- |----------------------- |-----|------ — | 
| qa | Quality Alert con | 
| | | | | | 
ig er aC aaa E [areas [peepee E LEE | 
| of (#) | Operation failure: [x | | 


Set-up failed ("sf"): 


Within the RequestedEvents (R:) structure, "sf" is used to request 
notification of a failed ATM OR AAL2 connection set-up. The ATM OR 
AAL2 connection set-ups addressed by "sf" are the same as for the 
"sc" event. 


In some ATM OR AAL2 applications with SVC set-up or bearer-signalled 
AAL2 path assignment, the "sf" event might not be used. In these 
cases, the following options are available: 


* the call agent receives a spontaneous delete from the media 
gateway with an appropriate reason code (902). 

* the call agent receives the "of" event described below with the 
optional reason code (902). 


Enable CAS via type 3 packets ("ec"): 


This signal indicates that the media gateway is to forward CAS 
signaling via type 3 packets on an AAL2 connection. This does not 
preclude the call agent from requesting notification of CAS state 
changes. On receiving this signal request, the gateway sustains a 
bidirectional type 3 CAS protocol over the AAL2 path. This comes to 
an end when the request is cancelled through a subsequent 
NotificationRequest command or when the VoAAL2 connection is deleted. 
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Enable DTMF tones via type 3 packets ("etd"): 


A gateway will ignore this signal request if it normally forwards and 
receives DIMF tones via type 3 packets. This signal indicates that 
the media gateway is to forward and receive DTMF tones via type 3 
packets on an AAL2 connection. This does not preclude the call agent 
from requesting notification of DTMF tones. 


Enable MF tones via type 3 packets ("etm"): 


A gateway will ignore this signal request if it normally forwards and 
receives MF tones via type 3 packets. This signal indicates that the 
media gateway is to forward and receive MF tones via type 3 packets 
on an AAL2 connection. This does not preclude the call agent from 
requesting notification of MF tones. This signal request does not 
Specify the MF tone type, which is known by other means. 


Enable R1 MF tones via type 3 packets ("etrl1"): 


A gateway will ignore this signal request if it normally forwards and 
receives R1 MF tones via type 3 packets. This signal indicates that 
the media gateway is to forward and receive R1 MF tones via type 3 
packets on an AAL2 connection. This does not preclude the call agent 
from requesting notification of R1 MF tones. 


Enable R2 MF tones via type 3 packets ("etr2"): 


A gateway will ignore this signal request if it normally forwards and 
receives R2 MF tones via type 3 packets. This signal indicates that 
the media gateway is to forward and receive R2 MF tones via type 3 
packets on an AAL2 connection. This does not preclude the call agent 
from requesting notification of R2 MF tones. 


Used codec changed ("uc (string)"): 


If armed via an R:atm/uc, a media gateway signals a codec change 
through an O:atm/uc. The alphanumeric string in parentheses is 
optional. It is the encoding name of the codec to which the switch 
is made. Although this event can be used with all ATM adaptations 
(AAL1, AAL2 and AAL5): 


The pftrans event is more suited to AAL2 applications. 
* Codec switches do not generally occur mid-call in AAL1 
applications. 
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Packet time changed ("ptime(#)"): 


If armed via an R:atm/ptime, a media gateway signals a packetization 


period change through an O:atm/ptime. The decimal number in 
parentheses is optional. It is the new packetization period in 
milliseconds. In AAL2 applications, the pftrans event can be used to 


cover packetization period changes (and codec changes). 
Profile element changed ("pftrans(#)"): 


If armed via an R:atm/pftrans, a media gateway signals a mid-call 
profile element change through an O:atm/ptime. This event is used 
with AAL2 adaptation only. A profile element is a row in a profile 
table. Profile elements indicating silence should not trigger this 
event. The decimal number in parentheses is optional. It is the row 
number to which the switch is made. Rows are counted downward, 
beginning from 1. 


Cell loss exceeded ("cle(#)"): 


This event indicates that the cell loss rate exceeds the threshold #. 
If the threshold is omitted in the requested events and observed 
events parameters, it is known by other means. The optional decimal 
number is the number of dropped cells per 100,000 cells. For 
example, cle(10) indicates cells are being dropped at a rate of 1 in 
10,000 celis. 


Packet loss exceeded ("ple(#)"): 


This event indicates that the packet loss rate exceeds the threshold 
4. If the threshold is omitted in the requested events and observed 
events parameters, it is known by other means. The optional decimal 
number is the number of dropped packets per 100,000 packets. For 
example, ple(10) indicates packets are being dropped at a rate of 1 
in 10,000 packets. 


When the bearer connection uses an AAL2 CID within a multiplexed VCC 
rather than an entire VCC, the 'ple' event is used instead of 'cle'. 
The packets are AAL2 CPS PDUs. 


Quality alert ("qa"): 


This event indicates that the bearer path fails to any predetermined 
combination of quality criteria such as loss, delay, jitter etc. 
This criterion is not defined and is left to the application. The 
gateway reports this quality violation to the call agent if armed to 
do so. 


Kumar Informational [Page 34] 


RFC 3441 ATM MGCP Package January 2003 


Report failure ("of (#)"): 


This indicates a connection failure. It can also indicate failure to 
establish a connection, in lieu of "sf". 


The most common response to these events is for the media gateway to 
delete the connection. Some applications might choose to report an 
"of" with the appropriate reason code, a decimal number, optionally 
included in parentheses. Reason codes are the same as for 
spontaneous deletes by the gateway. 


5.0 Connection Parameters 


The MGCP connection parameters structure is returned in an autonomous 
delete connection message, and in a response to a delete or audit 
connection command. The standard connections parameters [36] it 
contains are redefined below for ATM. Also, a new extension 
parameter specific to the ATM package is defined. 


The standard connection parameters redefined for ATM are: 


Number of packets sent: If a VCC is assigned to the connection, this 
is the total number of ATM cells transmitted for the duration of the 
connection. If a CID within an AAL2 VCC is assigned to the 
connection, it is the number of AAL2 common part sublayer (CPS) 
packets transmitted for the duration of the connection. 


Number of octets sent: If a VCC is assigned to the connection, this 
is the total number of ATM payload octets transmitted for the 
duration of the connection. If a CID within an AAL2 VCC is assigned 
to the connection, this is the total number of AAL2 CPS payload 
octets transmitted for the duration of the connection. 


Number of packets received: If a VCC is assigned to the connection, 
this is the total number of ATM cells received for the duration of 
the connection. If a CID within an AAL2 VCC is assigned to the 
connection, it is the number of AAL2 common part sublayer (CPS) 
packets received for the duration of the connection. 


Number of octets received: If a VCC is assigned to the connection, 
this is the total number of ATM payload octets received for the 
duration of the connection. If a CID within an AAL2 VCC is assigned 
to the connection, this is the total number of AAL2 CPS payload 
octets received for the duration of the connection. 


Number of packets lost: If a VCC is assigned to the connection, this 


is the total number of ATM cells lost for the duration of the 
connection, in the direction towards the gateway. If a CID within an 
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AAL2 VCC is assigned to the connection, it is the number of AAL2 
common part sublayer (CPS) packets lost for the duration of the 
connection, in the direction towards the gateway. If these losses 
cannot be assessed, then the gateway omits this parameter. 


Interarrival jitter: If a VCC is assigned to the connection, this is 
the interarrival jitter for ATM cells. If a CID within an AAL2 VCC 
is assigned to the connection, this is the interarrival jitter for 
AAL2 common part sublayer (CPS) packets. If this cannot be 
determined, then it is omitted or set to 0. 


Average Transmission Delay: This should be understood to be the 
average cell transmission delay in both cases: VCC assignment and CID 
assignment to the connection. This requires the use of ATM 
performance monitoring techniques. If it is not possible to assess 
this delay, it is omitted or set to 0. 


The following extension parameter is defined for the connection 
parameters structure: 


Connection qualification ("atm/CQ"): This qualifies the connection 
with enough granularity to be able to use the other connection 
parameters without a priori knowledge of network or connection type. 
Defined values are: 


1 ATM Virtual Circuit Connection (VCC) 
2 AAL2 Channel Identifier (CID) 
3 Direct transfer i.e., without an ATM or other 


packet path 


When omitted, the connection parameters must be interpreted on one of 
the following bases: 


The default interpretations for MGCP in Ref. 36. 
The call agent’s prior knowledge, if it governs the type of 
network and connection through the network type 'nt' LCO [Ref. 
36] and/or the connection type 'ct' LCO defined here. 

* The call agent’s snooping of the local connection descriptor 
provided by one or more media gateway. This is used to 
determine the network and connection type. 


An example of connection parameter encoding for an ATM VCC is the 
following: 


P: PS-1245, OS=59760, PR=1244, OR=59712, PL-20, JI=0, LA-0,atm/CQ-1 
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Note that the PL value refers to the receive direction and is 
unrelated to PS. Also, since atm/CQ=1, these parameters refer to ATM 
cells rather than to AAL2 CPS packets. 


As in other applications, any of these parameters can be omitted if 
not relevant to an application. Also, the entire P: structure is 
optional. 


When connection parameters are audited, all parameters normally 
returned with a delete connection are returned. This includes the 
connection qualification parameter, atm/CQ. 


The measurement or estimation of some or all of these connection 
parameters might not be feasible or beneficial in some applications. 
In such cases, these may be individually omitted, or the entire 
connection parameters structure, which is optional in MGCP, might be 
omitted. Further, parameters which indicate impairments might be set 
to 0 to nullify their impact, if any. 


6.0 Negotiation of Profiles and Codecs in ATM Applications 
6.1 Consistency of Parameters 


For ATM networks, the "nt" local connection option in MGCP must be 
set to "ATM". 


In any ATM application, the following Local Connection Options should 
not be used: 


Type of service, L: t 
Resource reservation, L: r 


This is because the Local Connection Options listed in Table 6 
provide information equivalent to the L: t and L: r local connection 


options. 


The following Local Connection Option is not meaningful in the AAL1 
case and should not be used: 


Packetization period, L: p 


In AAL2 applications, the following Local Connection Options should 
not be used: 


Encoding algorithm, L: a 
Packetization period, L: p 
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The following ATM Local Connection Options provide equivalent 
information in the AAL2 case: 


Profile list, L: atm/pfl 

Priority list of voice codec selections, L: atm/vsel 
Priority list of voiceband data passthrough codec selections, 
L: atm/dsel 

Priority list of fax codec selections, L: atm/fsel 


The use of a disallowed local connection option should be flagged 
with a return code of 524 (inconsistent local connection options). 
Although it is not recommended that these be ignored, it is 
recognized some applications choose to do so for the sake of backward 
compatibility. Note that the inconsistency in this case is between 
the local connection option (e.g., L:a) and the application (e.g., 
AAL2) which does not allow it. 


6.2 Codec/Profile Negotiation in ATM Networks 


In AAL1 and AAL5 applications, codec negotiation is similar to the IP 
case, although some of the local connection options and SDP 
connection descriptor parameters are different. See [18] for 
conventions for the use of the Session Description Protocol [26] in 
the ATM context. 


In AAL2 applications, the L:a and L:p parameters are disallowed. 
Profile negotiation takes the place of codec negotiation. The 
remainder of this section addresses how this is done. 


The specifics of the AAL2 bearer are not germane to profile 
negotiation. The bearer could be PVC-based or SVC-based, based on 
single-CID or multi-CID VCs, subcell multiplexed or not. 


The most general case involves different prioritized lists of 
profiles at the originating gateway, the terminating gateway, the 
originating call agent and the terminating call agent. Whether these 
lists are based on network policies, end subscriber service level 
agreements or equipment design is immaterial to the profile 
negotiation that is done as part of the connection establishment 
process. It is also irrelevant whether these lists are hardcoded 
defaults or provisionable. In the connection establishment process, 
a series of ordered intersections is performed. This leaves a single 
ordered list in the end. The highest priority profile in this list 
is the selected profile. 


Kumar Informational [Page 38] 


RFC 3441 ATM MGCP Package January 2003 


The call agent conveys its priority list through the pfl local 
connection option. The gateway conveys intersection results through 
the media information line in SDP [18]. Whether these lists imply a 
real priority or not, a profile is, as a general rule, preferred to 
profiles that follow it in a list. 


Each media gateway has a policy for assigning priorities to different 
lists (inter-list priority) which is different from the positional 
ordering of profiles within a list (intra-list priority). This 
policy might be a hardcoded default or provisioned. The inter-list 
priority specifies an ordering of the following lists with respect to 
each other: 


* "'C-list', which is the priority list from the call agent, 
received through L: atm/pfl. 

* "R-list', which is the priority list from the remote end, 
received through the SDP remote connection descriptor. 

* "L-list', which is the local priority list, hardcoded or 
provisioned. 


Depending on the application, different inter-list priorities may be 
used in cases where the gateway originates and terminates a call. 


The policy mentioned above will vary depending on the type, 
capabilities and deployment of the media gateway. Network 
administrations or equipment vendors will provision/default this 
policy for various reasons such as resource usage optimization, 
quality of service, likelihood of finding a common profile etc. 


When doing an ordered intersection of lists, the intra-list 
priorities of the highest priority list are used. Any profile that 
cannot be supported due to resource (bandwidth, processing power 
etc.) limitations is eliminated from the intersection. 


In the absence of one or more of these lists, the remaining list(s) 
are used in the profile selection process. If the call agent does 
not provide a list of profiles, the C-list is absent. In this case, 
the intersection of the C-list, R-list and L-list simply becomes the 
intersection of the R-list and the L-list. If the R-list is also 
absent, no intersection is performed and the result of this null 
operation is the L-list. Previous values, if any, of the C-list and 
R-list are not used. 
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The process of profile negotiation is as shown below: 


ORIGINATING TERMINATING 
GATEWAY GATEWAY 


(1) On receiving CRCX 
do a policy-based ordered 
intersection of the C-list, 
and L-list. No R-list present. 


(2)Send resulting ordered list 
to the terminating gateway 


via SDP. 

(3) On receiving CRCX do 
a policy-based 
ordered 
intersection of the 
C-list, R-list and 
L-list. 

(4) The highest priority 
profile in the 
resulting 
list is the 
selected 

profile. 
< ini dein pi Euh, jns Eus de Men juil pact Raps yep M par aos Vn del E 9 epar Ry eie iudei jua! Quot aic ne jo qe ee GEN id 


(5) Send selected profile 
to the originating gateway 
via SDP. 


Prior to receiving the final profile in step 5, if the originating 
gateway has indicated multiple profiles in step 2, the originating 
gateway does not always have a usable basis for decoding AAL2 


packets. This is because a combination of packet length and UUI 
(user-to-user indication) codepoint range may indicate different 
codecs in different profiles. The time lag between when the 


terminating gateways start sending AAL2 packets and when the 
originating gateway becomes aware of the selected AAL2 profile should 
be minimized so that any ensuing clipping of the front-end of the 
audio stream is tolerable for voice circuits. It is unlikely that 
this will introduce errors in modem or fax circuits since these will 
not have entered their user data transfer phase at this time. 


When connection establishment is complete, there is only one profile 
associated with a connection. This implies that both endpoints are 

ready to receive, on the fly, packets that comply with any row in the 
profile. Some applications may elect to associate profile rows with 
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one or more of the following service types: voice service, voiceband 
data (modem) passthrough service and fax service. This binding can 
be by default, through provisioning or as part of profile negotiation 
during call establishment. Such service type associations, when 
communicated to another entity, are advisory and do not limit the 
requirement for supporting, at any time, on-the-fly switches to any 
profile element. 


Media gateways can have internal default (or provisioned) bindings 
between service types and profile elements. Note that not all of 
these bindings might be meaningful in an application context (e.g., 
the fax service binding might be ignored and omitted). As part of 
profile negotiation, applications might choose to coordinate those 
bindings that are meaningful. When this is done, the vsel, dsel and 
fsel LCOs described in this document, and the vsel, dsel and fsel 
media attribute lines [18] are used to effect this coordination. 
Using these constructs, entities such as call agents and media 
gateways can indicate preferred bindings for the first, most 
preferred profile in a profile list. 


When performing ordered intersections of the C-list, L-list and 
R-list in the call flow above, media gateways MUST use the inter-list 
priority to choose between a service to profile row binding suggested 
by the call agent, the remote gateway or it own internal (provisioned 
or default) binding. Thus, a service type to profile row binding 
inherits its relative priority from the profile list generated by the 
same source. If the C-list has the highest priority, and the first 
profile in the C-list is selected as the first profile of the 
intersected list, then any service type to profile row bindings 
provided by the call agent via the vsel, dsel and fsel LCOs are 
associated with the first profile. If the R-list has the highest 
priority, and the first profile in the R-list is selected as the 
first profile of the intersected list, then any service type to 
profile row bindings provided by the remote gateway via the vsel, 
dsel and fsel SDP attributes [18] are associated with the first 
profile. If the L-list has the highest priority, then any internal 
(default or provisioned) service to profile row bindings are 
associated with the first profile. At the end of profile negotiation 
(step 4 in the call flow above), there is one profile selected by the 
terminating media gateway. It MAY convey any applicable service type 
to profile row bindings for this profile to the originating gateway 
via the vsel, dsel and fsel SDP attributes [18]. 


If the first profile in the intersected list is not the first profile 
in the highest priority profile list, then any service to profile row 
bindings associated with the highest priority profile list cannot be 
used with the first (or only profile) in the intersected list. In 
this case, the originating or terminating media gateway MUST attempt 
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to associate internal (default or provisioned) service to profile row 
bindings with the first (or only profile) in the intersected list. 


Since there is more than one service type, it is possible that the 
service type to profile row bindings for the first profile in the 
intersected list be derived from different sources (the call agent, 
the remote media gateway, internal defaults or provisioning). For 
consistency, if the voiceband data (passthrough) service mappings 
include fax, then a different set of fax service mappings cannot 
apply to the profile under consideration. If applied in this case, 
the set of fax service mappings must include the same codecs, packet 
lengths and packetization periods as the voiceband data service 
mappings. However, they may be in a different order. 


If the media gateway lumps fax service with voiceband data (modem) 
passthrough service, then it can ignore any fax service to profile 
row bindings provided by another entity such as the call agent or the 
remote gateway. From the media gateway’s perspective, there is no 
distinct fax service in this case. In this case, the media gateway 
will not indicate a separate preference for the use of certain 
profile rows in conjunction with fax service. 


It is possible that the procedure described in this section for 
associating service types with profile rows fail to yield mappings 
between a given service type and the row(s) of the first profile in 
the intersected list of profiles. This is acceptable since these 
bindings are merely indications of the preferred codecs and 
packetizations in the context of a given service. They do not 
obviate the AAL2 requirement that, given a profile that is bound to a 
connection, a transmitter may switch to any profile row on the fly. 


An example of profile negotiation: 


The L-list at gateway #1, which is the originating gateway in this 
example, is: 


custom 100, itu 3, itu 1, itu 8 


Kumar Informational [Page 42] 


RFC 3441 ATM MGCP Package January 2003 


The L-list at gateway #2, which is the terminating gateway in this 
example, is: 


itu 2, itu 3, itu 1, itu 5 


The originating call agent sends the following profile list (C-list) 
to the originating gateway in the first create connection command: 


itu 8, itu 9, atmf 7, itu 3, itu 1, custom 100 


Further, the originating call agent qualifies the first profile in 
its list with the following service type bindings: 


L: atm/vsel:"G729 10 10000", atm/dsel:"on PCMU 40 5000" 


There is no atm/fsel local connection option. Facsimile is included 
with voiceband data in the atm/dsel local connection option. 


In step 1 at the originating gateway, there is no remote connection 
descriptor, hence no R-list. The policy for originating calls at 
gateway #1 is: 


C-List > R-list > L-list 


where '»' means 'has higher priority than’. The term 'R-list' can be 
omitted from this series of inequalities since, in case under study, 
profile negotiation does not include any further ordered 
intersections at the originating gateway. 


In accordance with this policy, the originating gateway performs an 
ordered intersection of the C-list and the L-list to produce: 


itu 8, itu 3, itu 1, custom 100 


Since the C-list has the highest priority and the first profile in 
the intersected profile list is also the first profile in the C-list, 
the service bindings provided by the originating call agent are 
associated with the first profile, itu 8. The originating gateway 
sends this result(intersected profile list and service bindings for 
the first profile, itu 8) via the SDP remote session descriptor to 
the terminating gateway. The service bindings are expressed as 
follows [18]: 


a-vsel:G729 10 10000 
a-dsel:on PCMU 40 5000 


Kumar Informational [Page 43] 


RFC 3441 ATM MGCP Package January 2003 


The intersected profile list produced by gateway 1 becomes the R-list 
for gateway #2. The terminating call agent sends the following 
profile list (C-list) to the terminating gateway in the first create 
connection command: 


3tu-ct, itu 4, itu 3, custom 110, custom 100, itu 2 


Any service bindings (not shown) sent by the terminating call agent 
apply to the first profile in this list, itu 1. 


The policy for terminating calls at gateway 42 is: 
R-list > L-list > C-list 


Using this policy, gateway #2 produces the following ordered 
intersection of R-list, L-list and C-list: 


itu 3, itu 1 


The first profile in this list, itu 3, is to be used for this 
connection. Gateway 2 indicates this to the call agent through the 
SDP local connection descriptor. 


Note that the service bindings provided by the originating gateway 
have not been specified with respect to itu 3. Therefore, these 
cannot be used even though the R-list has the highest priority at the 
terminating gateway. Any existing internal (default or provisioned) 
service bindings for AAL2 profile itu 3 must be associated by the 
terminating gateway with the selected profile, itu 3. Those service 
bindings that are internally unavailable are left unspecified. 


Since the internal service type bindings do exist for the profile itu 
3 at the terminating gateway, they are selected and bound to the 
connection. In these, fax service is lumped with voiceband data 
passthrough. These bindings are indicated to the originating gateway 
via the following SDP media attribute lines: 


a-vsel:G726-32 20 5000 G726-24 15 5000 
a-dsel:on PCMU 40 5000 G726-40 25 5000 
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The vsel line maps voice service to certain rows in the itu 3 profile 
table. The dsel line maps voiceband data service to certain rows in 
the itu 3 profile table. The "on" in the dsel line indicates that 
voiceband data includes fax, otherwise a separate fsel line might 
have been used. Two codecs each are indicated for voice and for 
voiceband data, with the first codec being the preferred one. 
Although the originating gateway is not constrained by these advisory 
indications of profile element to service type mapping, applications 
may choose to limit on-the-fly switches based on the current service 
state (voice, voiceband data etc.). If done, this provides greater 
simplicity at the expense of flexibility. 


7.0 Security Considerations 
The ATM package extends the base Media Gateway Control Protocol 
(MGCP) [36]. This package specifies no additional security 
requirements or recommendations over those of the base MGCP protocol. 
8.0 IANA Considerations 
The ATM package described in this document has been registered as an 
MGCP package under the name "atm", without the quotes. The current 
version of this package is 0 (default). This registration has been 


completed per the IANA considerations in the MGCP specification [36]. 


The contact for the MGCP ATM package is the author of this document 
(Section 12). 
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10.0 Acronyms 


AAL ATM Adaptation Layer 

ABR Available Bit Rate 

ABT/DT ATM Block Transfer/Delayed Transmission 
ABT/IT ATM Block Transfer/Immediate Transmission 
ATM Asynchronous Transfer Mode 

ATMF ATM Forum 

BCG Bearer Connection Group 

CAS Channel Associated Signaling 

CBR Constant Bit Rate 

CDV Cell Delay Variation 

CDVT Cell Delay Variation Tolerance 

CID Channel Identifier 

CLR Cell Loss Ratio 

CPS Common Part Sublayer 

DBR Deterministic Bit Rate 

FEC Forward Error Correction 

FRF Frame Relay Format 

GFR Guaranteed Frame Rate 

GWID Gateway Identifier 

IP Internet Protocol 

ITU International Telecommunications Union 
LCO Local Connection Option 

MBS Maximum Burst Size 

MCR Minimum Cell Rate 

MFS Maximum Frame Size 

MGCP Media Gateway Control Protocol 

nrt-VBR Non-real-time Variable Bit Rate 
NSAP Network Service Access Point 

PCR Peak Cell Rate 

PDU Protocol Data Unit 

PVC Permanent Virtual Circuit 

QoS Quality of Service 

rt-VBR Real-time Variable Bit Rate 

SAR Segmentation and Re-assembly 

SCR Sustained Cell Rate 

SDT Structured Data Transfer 

SDU Service Data Unit 

SPVC Switched Permanent Virtual Circuit 
SRTS Synchronous Residual Time-Stamp 

SSCOP Service-specific Connection Oriented Protocol 
SSSAR Service-specific Segmentation and Re-assembly 
SVC Switched Virtual Circuit 

TDM  Time-Division Multiplexing 

UBR Unspecified Bit Rate 

UDT Unstructured Data Transfer 

VC Virtual Circuit 
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VCCI Virtual Circuit Connection Identifier 
VCI Virtual Circuit Identifier 

VP Virtual Path 

VPCI Virtual Path Connection Identifier 
VPI Virtual Path Identifier 
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